1. Field of the Invention
The present invention relates to an Internet Protocol compliant private branch electronic exchange and a method for redundantly configuring terminal interfaces and its program. In particular, the invention relates to a redundant configuration of terminal interfaces which interface with terminals falling under the control of the Internet compliant private branch electronic exchange.
2. Description of the Related Art
In a prior art Internet Protocol compliant private branch electronic exchange [hereinafter referred to as “IP-PBX” (Internet Protocol-Private Branch exchange)], a Multimedia Gateway Controller (MGC) that performs call-control-processing tasks has Local Area Network (LAN) ports and connects these ports to the Internet, an intranet, or a LAN. In this case, the LAN is a network that may be Ethernet (registered trademark).
Using the MGC, the IP-PBX conducts control of Internet Protocol (IP) compliant phones (hereinafter referred to as “IP phones”) that may connect to the Internet or an intranet and a terminal adapter [hereinafter referred to as IPTA (Internet Protocol Terminal Adapter)] which accommodates terminals not compliant with IP and attaches IP to the terminals.
In the IP-PBX, a redundant configuration of terminal interfaces when connecting to a LAN that accommodates IP phones is accomplished by applying a Virtual Router Redundancy Protocol (VRRP) which is performed on a router. This method is referred to as a first method.
A redundant configuration of the terminal interfaces is also practiced in such a manner that the IP addresses of two interfaces to which an IP phone may connect are given to the IP phone and a procedure is performed in which the IP phone inquires which of the two interfaces identified by the respective IP addresses controls it. This method is referred to as a second method.
First, the first method will now be explained with reference to FIG. 12. In FIG. 12, the IP-PBX 60 includes an MGC 61 and the MGC 61 has a memory 63 connecting to a main processor (MP) 62 and a call control data master table 631 created in the memory 63.
The main processor 62 connects to a LAN interface 64-1 through a system bus 400 and the LAN interface 64-1 connects to a switching hub 5-1 via a LAN 200. The switching hub 5-1 connects to a network [for example, a Wide Area Network (WAN) 300] through a router 6.
On the other hand, IP phones 7-1, 7-2 or an IPTA 8 that accommodates non-IP phones 9-1, 9-2 connects to a switching hub 5-3 and the switching hub 5-3 connects to the network via the router 6. By these connections, the MGC 61 is bound to be able to conduct call control for the IP phones 7-1, 7-2 or non-IP phones 9-1, 9-2 accommodated by the IPTA 8. A LAN interface 64-2 is a duplicate of the LAN interface 64-1 in a redundant configuration and the LAN interface 64-2 and the LAN interface 64-1 are assigned the same IP address.
The main processor 62 of the MGC 61 generates IP packets in a packet format of Transmission Control Protocol/Internet Protocol (TCP/IP) or User Datagram Protocol (UDP) and the LAN interface 64-1 transmits the IP packets. On the other hand, IP packets from the terminals being under the control of the IP-PBX, such as the IP phone 7-1, are received by the LAN interface 64-1, and the main processor 62 extracts call control data from the IP packets.
In the above configuration, the LAN interface 64-1 operates as a master and a VRRP procedure is effected between the LAN interface 64-1 and the LAN interface 64-2. The LAN interface 64-1 gives interface data to the LAN interface 64-2.
Both the LAN interface 64-1 and the LAN interface 64-2 are virtually recognized by the IP phones 7-1, 7-2, IPTA 8, and switching hub 5-1 as one interface with one IP address. That is, when the LAN interface 64-1 is operating, the LAN interface 64-2 is on standby and does not access the LA 200. Thus, an access point from the terminals is one IP address for the LAN interfaces 64-1, 64-2.
In this connection, if the LAN interface 64-1 has failed, the LAN interface 64-2 is put into operation, according to the VRRP procedure, so that the ongoing call control procedure can continue. In that event, the IP address as the access point from the terminals remains unchanged. During the operation of the LAN interface 64-2, when the LAN interface 64-1 has recovered from the failure, the LAN interface 64-2 returns to the standby state.
Then, the second method will be explained with reference to FIG. 13. Although the same configuration as for the above-described first method is shown in FIG. 13, the second method differs from the first method in that the VRRP procedure is not performed and the LAN interface 64-2 and LAN interface 64-1 are assigned different IP addresses.
In the above configuration, for example, on the IP phone 7-1, as the LAN interfaces to which it is to connect, initially, the LAN interface 64-1 is set for the master and the LAN interface 64-2 for the slave. Two IP addresses: IP address A of the LAN interface 64-1 and IP address B of the LAN interface 64-2 are stored in the memory of the IP phone.
The IP phone 7-1 periodically verifies the proper performance of the LAN interface 64-1, using a PING packet or the like. As long as the LAN interface 64-1 continues to operate properly, call control packets from the IP phone 7-1 are sent to the LAN interface 64-1.
Meanwhile, in the event that the IP phone 7-1 cannot verify the proper performance of the LAN interface 64-1, the initial setting changes; the LAN interface 64-2 becomes the master and the LAN interface 64-1 becomes the slave. Then, the phone 7-1 periodically verifies the proper performance of the LAN interface 64-2, using the PING packet or the like. As long as the LAN interface 64-2 continues to operate properly, call control packets from the IP phone 7-1 are sent to the LAN interface 64-2.
In the foregoing prior art redundant configuration of terminal interfaces, where the first method or the second method is applied, pairs of LAN interfaces must be installed as the terminal interfaces.
The similar redundant configuration is applied to routers and the number of the routers on the network is limited. By contrast, the number of terminal interfaces or LAN interfaces of the IP-PBX must be increased with increase in the number of terminals accommodated by the IP-PBX. Accordingly, such a problem is posed when the forgoing prior art methods apply to the terminal interfaces that the total cost required is the number of LAN interfaces×the cost of a LAN interface×2 (duplication); that is, the cost is double the cost of installing the LAN interfaces dispensing with the redundant configuration.
A problem associated with the second prior art method for redundantly configuring terminal interfaces is as follows. This method realizes a redundant configuration of terminal interfaces that can be recognized from the viewpoint of the terminals falling under the control of the IP-PBX, such as IP phones and IPTAs that are accommodated by the IP-PBX. LAN interface changeover is not performed upon failure detection by the MGC and the LAN interfaces. Each of the above terminals verifies proper interface performance and changes the LAN interface selected when it detects the failure of the interface performance. For verifying proper interface performance, packets must be sent and received between the interface and the terminal and, consequently, the packet traffic over the network increases.
In short, the problem with the second method is an increase in the packet traffic over the LAN due to that a plurality of IP phones which are verifying the performance of the LAN interface to which they are connecting, decreases LAN performance. Interface duplications for redundancy by the second method, that is, LAN interfaces must always be installed in pairs and, accordingly, the cost increases. The cost increase would be serious when the number of terminals accommodated by the IP-PBX expands and it is necessary to expand the number of LAN interfaces. Also, a great number of IP addresses to be assigned to the LAN interfaces must be employed. A congestion problem may occur, for example, when the number of terminals accommodated by the IP-PBX reaches several thousands and over and call origination attempts from the terminals are congested. That is, the origination attempts may become hard for the LAN interfaces to serve (in call procedures for processing them).
Furthermore, another problem may be presented when a failure has occurred in the network, for example, a router fault or wiring fault between the LAN interfaces and the terminals falling under the control of the IP-PBX. In that event, the packets for verifying proper interface performance from the terminals cannot be sent and received therebetween and, consequently, the terminals change over the LAN interface to which they connect.
Also, another drawback of the second method is employing an exceedingly great number of IP addresses for the LAN interfaces because the IP addresses must be assigned to all the LAN interfaces, whether they are operating or on standby.